WORLD INTELLECTUAL PROPERTY ORGANIZATION 
International Bureau 




PCT 

INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(51) Internationa] Patent Classification 7 
H04M 7/00, H04Q 11/04 



Al 



(11) International Publication Number: 
(43) International Publication Date: 



WO 00/42760 

20 July 2000 (20.07.00) 



(21) International Application Number: PCT/SE99/02490 

(22) International Filing Date: 28 December 1999 (28.12.99) 



(30) Priority Data: 

60/116,198 
09/472,410 



15 January 1999 (15.01.99) US 
27 December 1 999 (27. 1 2.99) US 



(71) Applicant: TELEFON AKTIEB OL AGET LM ERICSSON 

(publ) [SE/SE]; S-126 25 Stockholm (SE). 

(72) Inventors: GLITHO, Roch; 4530 Beaconsfield, Montreal, 

Quebec H4A 2H7 (CA). GOURRAUD, Christophe; 5470 
rue Duquette, Montreal, Quebec H4A 1J6 (CA). 

(74) Agent: NORIN, Klas; Ericsson Radio Systems AB, Common 
Patent Dept., S-164 80 Stockholm (SE). 



(81) Designated States: AE, AL, AM, AT, AU, AZ, BA, BB, BG, 
BR, BY, CA, CH, CN, CR, CU, CZ, DE, DK, DM, EE, 
ES, FI, GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, IS, JP, 
KE, KG, KP, KR, KZ, LC, LK, LR, LS, LT, LU, LV, MA, 
MD, MG, MK, MN, MW, MX, NO, NZ, PL, PT, RO, RU, 
SD, SE, SG, SI, SK, SL, TJ, TM, TR, TT, TZ, UA, UG, 
UZ, VN, YU, ZA, ZW, ARIPO patent (GH, GM, KE, LS, 
MW, SD, SL, SZ, TZ, UG, ZW), Eurasian patent (AM, AZ, 
BY, KG, KZ, MD, RU, TJ, TM), European patent (AT, BE, 
CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, IT, LU, MC, 
NL, PT, SE), OAPI patent (BF, BJ, CF, CG, CI, CM, GA, 
GN, GW, ML, MR, NE, SN, TD, TG). 



Published 

With international search report. 

Before the expiration of the time limit for amending the 
claims and to be republished in the event of the receipt of 
amendments. 



(54) Title: SYSTEM AND METHOD FOR PROVIDING ACCESS TO SERVICE NODES FROM ENTITIES DISPOSED IN AN 
INTEGRATED TELECOMMUNICATIONS NETWORK 

(57) Abstract 

A system and 
method of accessing 
services from end 
terminals disposed in an 
integrated telecommuni- 
cations network having a 
packet-switched network 
(PSN) portion such as 
for example, a network 
portion using the Internet 
Protocol (IP) and a 
circuit-switched network 
(CSN) portion such as, 
for example, a wireless 
telephony network 
portion. The PSN portion 
is preferably realized 
a Voice-over-IP 
(VoIP) network having 
a gateway connected 
to the CSN portion. A 
service or application 
node, preferably a 
WIN/IN-based service 
node comprising a Service 
Control Point (SCP), a 

Service Data Point (SDP), or both, is provided with an interface operable with the PSN portion. A call control state machine associated 
with the end terminals is modified to include WIN/IN-compliant DPS. A user profile retriever provided in the network also When the 
call control process of the end terminal encounters an armed DP, it creates a Service Access instance as part of a service access server and 
passes control thereto, wherein a service proxy sends a request to a service logic environment, preferably provided as the WIN/IN service 
node. Upon executing an appropriate service logic portion or portions, the service node returns a result to the service access server which 
in turn, passes it to the call control process. 



172C 



I72B 








INTELLIGENT 
TERMINAL-) 




172A 



1 



BNSDOCID: <WO 0042760 A 1J_> 



f 



AL 

AM 

AT 

AU 

AZ 

BA 

BB 

BE 

BF 

BG 

BJ 

BR 

BY 

CA 

CF 

CG 

CH 

CI 

CM 

CN 

CU 

CZ 

DE 

DK - 
EE 



Codes used to identify 

Albania 

Armenia 

Austria 

Australia 

Azerbaijan 

Bosnia and Herzegovina 

Barbados 

Belgium 

Burkina Faso 

Bulgaria 

Benin 

Brazil 

Belarus 

Canada 

Central African Republic 

Congo 

Switzerland 
Cdte d'lvoire 
Cameroon 
China 
Cuba 

Czech Republic 

Germany 

Eenlriark 



FOR THE PURPOSES OF INFORMATION ONLY 
States party to the PCT on the front 



FI 
FR 
GA 
GB 
GE 
GH 
GN 

GR 

HU 

IE 

IL 

IS 

IT 

JP 

KE 

KG 

KP 

KR 

KZ 
LC 

-LI 

LK 
LR 



Spain 
Finland 
France 
Gabon 

United Kingdom 

Georgia 

Ghana 

Guinea 

Greece 

Hungary 

Ireland 

Israel 

Iceland 

Italy 

Japan 

Kenya 

Kyrgyzstan 

Democratic People's 

Republic of Korea 

Republic of Korea 

Kazakstan 

Saint Lucia 

-Liechtenstein 

Sri Lanka 
Liberia 



pages of pamphlets publishing international applications 



under the PCT. 



LS 
LT 
LU 
LV 
MC 
MD 
MG 
MK 

ML 

MN 

MR 

MW 

MX 

NE 

NL 

NO 

NZ 
PL 
PT 
RO 

RU 



Lesotho 

Lithuania 

Luxembourg 

Latvia 

Monaco 

Republic of Moldova 

Madagascar 

The former Yugoslav 

Republic of Macedonia 

Mali 

Mongolia 

Mauritania 

Malawi 

Mexico 

Niger 

Netherlands 

Norway 

New Zealand 

Poland 

Portugal 

Romania 

Russian-Federation 

Sudan 

Sweden 

Singapore 



SI Slovenia 

SK Slovakia 

SN Senegal 

SZ Swaziland 

TD chad 
TG Togo 
T J Tajikistan 
T M Turkmenistan 

TR Turkey 

Trinidad and Tobago 

UA Ukraine 

UG Uganda 

US United States of America 

Uzbekistan 

VN Viet Nam 

VU Yugoslavia 

ZW Zimbabwe 



BNSDOCID: <WO 0042760A 1_l_> 



WO 00/42760 PCT/SE99/02490 



SYSTEM AND METHOD FOR PROVIDING 
ACCESS TO SERVICE NODES FROM ENTITIES DISPOSED IN AN 
INTEGRATED TELECOMMUNICATIONS NETWORK 

5 PRIORITY STATEMENT UNDER 35 U.S.C §1 19(e) & 37 C.F.R. §1.78 

This nonprovisional application claims priority based upon the following prior U. S . 
provisional patent application entitled: "Enhancing Supplementary Services through the Use 
of Intelligent Network Principles and Accessing Service Nodes from End Terminals," Ser. 
No. 60/1 1 6, 1 98 (prior Attorney Docket Number 2795 0-296L, current Attorney Docket 
1 0 Number 1 000-0 1 42), filed January 15,1 999, in the names of: Roch Glitho and Christophe 
Gourraud. 

CROSS-REFERENCE TO RELATED APPLICATIONS 

This application discloses subject matter related to the subject matter disclosed in 
15 the following co-assigned patent application: "System and Method for Providing 

Supplementary Services (SS) in an Integrated Telecommunications Network," filed 

December 1 0, 1 999, Ser. No. (Attorney Docket Number 1 000-0 1 42), in the 

names of: Roch Glitho and Christophe Gourraud. 

20 BACKGROUND OF THE INVENTION 

Technical Field of the Invention 

The present invention relates to integrated telecommunication systems and, more 
particularly, to a system and method for providing access to service nodes from entities 
(e.g., endpoints, terminals, gatekeepers, etc.) disposed in an integrated telecommunications 
25 network. The exemplary integrated telecommunications network may comprise a packet- 
switched network (PSN) coupled to a circuit-switched network (CSN). Also, the network 
may comprise a PSN portion only. 
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Supplementary Services) in VoIP networks. The IP-based VAS architecture is based on 
the notion that because telephony call control logically resides within the end terminals of the 
network, service implementation should preferably be localized therein also. This 
architecture makes terminals the primary actors for IP VAS. On the other hand, there exists 
5 an Intelligent Network (IN) or Wireless Intelligent Network (WIN) service architecture for 
providing VAS in the context of CSNs. The WIN/IN service architecture is network- 
centric, that is, service implementation is done in the network, with centralized sendee logic 
in a service node (e.g., a Service Control Point or SCP) that is accessed by switching 
entities. Applied to IP telephony, this implies access from such entities as gatekeepers (in 
0 H.323 networks) or proxy/redirect servers (in SIP networks). 

It should be apparent to those skilled in the art that each of the VAS approaches 
set forth above has its own shortcomings and deficiencies. For instance, in IP-based VAS 
architectures, a significant concern is that the architecture does not address sendee mobility 
(i.e., end-user can access the services regardless of the terminal/appliance used). Also, 
5 typically a small number of services are provided in these approaches, which tend to be 

rather simple as well. Further, as the number of services available increases, the issue of 
service interaction becomes more significant because there is no centralized logic for 
resolving contentions or conflicts among the services. 

In the case ofWIN/IN service architectures, a principal drawback is the complexity 
) of the CSN itself Also, another significant shortcoming is that network-based service 
architectures do not scale reliably as the number of available: services keeps increasing 

As is well known, there have been several VAS solutions, depending upon the 
particular standard used in IP telephony. For example, the H.323 standard comes 
equipped with the H.450 protocol for Supplementary Services (SS). Similarly, there are 
> solutions such as Call Processing Language (CPL) for the SIP-based IP telephony. Also, 
there exist Application Programming Interface (API)-based solutions such as, e.g. , Parlay, 
VHE/OSA, etc. 

However, it should be appreciated by those of ordinary skill in the art that several 
shortcomings and weaknesses exist in the state-of-the-art service provisioning schemes in 
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scripts (e.g., SIP CPL, SIP CGI, etc.), or mobile agents — are implemented as within a 
universally accessible Service Logic Environment or Environments. 

Further, the service proxies and the Service Access component operate in concert 
as a Service Access server to provide access to local services, mobile agent services, or 
5 remote service nodes in an appropriate Service Logic Environment. A user profile used by 

the various components to invoke the right services at the right time is included in the service 
architecture. This user profile may partly be co-resident with the call control module, or 
reside at a remote location that is retrievable. In addition, the profile may preferably be 
modifiable by various applications, including services implemented as mobile agents. 

10 In one aspect, the present invention is directed to method of accessing a service 

node, preferably, e.g., a Wireless Intelligent Network (WIN) node, from an end terminal 
disposed in an integrated telecommunications network having a Voice-over-Internet 
Protocol ( VoIP)-based PSN portion and a cellular network portion. An interface module 
is disposed between the service node and the PSN- VoIP portion. The method 

1 5 incorporates one or more detection points (DPs) in a call control process provided with the 

end terminal. The DPs are preferably WIN-compliant, and operate to pass control to a 
Service Access instance of the Service Access server when the call control process 
encounters an armed DP of appropriate type. Thereafter, the Service Access server 
determines if one or more services need to be executed. If so, a service request is sent from 

20 a service proxy of the Service Access server to the service node for service execution. 

Responsive to the service request, a result is received in the Service Access server from the 
service node. Subsequently, the result is forwarded from the Service Access server to the 
call control process of the end terminal. 

In another aspect, the present invention is directed to a service provisioning method 

25 for invoking a WIN service by an end terminal disposed in an integrated telecommunications 

network having a PSN- VoIP portion and a cellular network portion. The method 
commences by first effectuating a call control process in the end terminal . A determination 
is made in the end terminal if an armed DP associated with a service request is encountered 
by the call control process. The call control process then creates a suitable Service Access 
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FIG. IB depicts a functional block diagram of an exemplary embodiment of an 
integrated telecommunications network having anH.323-based network portion and a 
cellular network portion, wherein the teachings of the present invention are advantageously 
employed; 

5 FIG. 1C depicts a functional block diagram indicating signal flow paths of a 

presently preferred exemplary embodiment of a service provisioning architecture in an 
integrated telecommunications network with an H.323-based VoIP portion; 

FIG. 2 A depicts a high-level functional model of a service provisioning scheme for 
use in an integrated telecommunications network, 
1 0 FIG. 2B depicts a functional block diagram of a VAS-enabled terminal which can 

interact with a user profile retriever in accordance with the teachings of the present 
invention; 

FIG. 2C depicts a flow chart of an exemplary embodiment of a service provisioning 
method for use in an integrated telecommunications network; 
1 5 FIG. 2D depicts a generalized user profile model for use with a service invocation 

and realization architecture provided in accordance with the teachings of the present 
invention; 

FIG. 3 depicts a functional block diagram of a VAS architecture provided in 
accordance with the teachings of the present invention; 
20 FIG. 4 depicts a WIN-compliant Originating Call Control State Machine 

(OCCSM) for use with an H.323 terminal or a SIP terminal; 

FIG. 5A depicts a WIN-compliant Terminating Call Control State Machine 
(TCCSM) for use with an H.323 terminal; 

FIG. 5B depicts a WIN-compliant Terminating Call Control State Machine 
25 (T_CCSM) for use with a SIP terminal; 

FIGS. 6 A and 6B depict message flow diagrams for two exemplary embodiments 
of a call diversion service, respectively, in accordance with the teachings of the present 
invention; 

FIG. 7 depicts a message flow diagram for a hunt group service in accordance with 
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the teachings of the present invention; and 

with «. ^^^"^^"'^"^^'-^^ontnaccordanee 
with the teachings of the present invention 
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IP network portion 196 and a circuit-switched cellular network portion 194 of the 
telecommunications network 1 98 . One or more service nodes including at least a Service 
Control Point (SCP), for example, SCP service node 190, optimized for providing 
advanced services in the framework of WIN/IN architecture, is provided as part of the 
5 infrastructure of the circuit-switched cellular network portion 194. Furthermore, in 

accordance with the teachings of the present invention, a service node converter interface 
(I/F) may be provided between the H.323 network portion 1 96 and the SCP service node 
190 such that an H.323 entity, e.g., a gatekeeper or a terminal, can interrogate the service 
node 1 90 for invoking a subscriber service. Preferably, the converter (not shown in this 

1 0 FIG.) is associated with a communication path 1 65, using SS7 or IP, between the H.323 

portion 196 and the service node 190. A plurality of "intelligent" H.323 terminals (i.e., 
"service-active" or "service-capable" terminals), e.g., terminal- 1 172 A (TA) through 
terminal-3 172C (TC), one or more gatekeepers (GKs), e.g., GK-1 174 A and GK-2 
1 74B, and an MCU 1 70 are disposed in the H.323 network portion 1 96 in a conventional 

1 5 manner. 

In accordance with the teachings of the present invention, a user profile repository 
1 68 is provided as part of the telecommunications network 1 98 for generating triggers to 
the service node 190. The user profile repository 168 is interfaced within the H.323 
network portion via a suitable interface 1 67 such as a HyperText Transfer Protocol (HTTP) 

20 interface or Lightweight Directory Access Protocol (LD AP) interface. A user profile 

retriever (not explicitly depicted in this FIG.) is included for retrieving user profile 
information to be provided to various call/service components, as will be discussed in 
greater detail hereinbelow. 

Whether a trigger should be generated to the service node 1 90 depends on the 

25 VAS activated in the network 198, in addition to whether the end-user has an active 

subscription to it. In order to determine when to suspend and generate triggers, a call 
control entity (shown in FIG. 2B hereinbelow) is provided with the capability to 
interface/interact with the user profile retriever to obtain a set of triggers (i. e. , end-user 
profile) associated with the end-user. However, it should be appreciated that some 
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constant services, not subject to explicit subscription, or for performance reasons, rnay give 
nsetosomeservice triggering stored locally (that is, within anH.323 entity suchasa 
terminal, gatekeeper, or a media gateway controller (MGQ). Further, while the user 

pronlerepository,68isshowninthisexemplaryembodimentasa S eparateentity,it should 
beunderstood that the reposkory may be co-located with an IP mobilhy management entity 
or the service node 190 itself. 

In the presently preferred exemplary embodiment of the present invention the 
service node 190 may be accessed by a host of H.323 entities such as the terminals 
gatekeepers, media gateway controllers, etc. Forexample, FIG. 1C depots a functional 

blockdiagramwithsignalflowpathsforeffectuatingservicenodeaccessinanexemplary 
embod,ment of an H.323 VoIP network wherein an IP terminal is provided with the 
capabilityofaccessingaservicenode, e.g., SCP service node 190 Those of ordinary skill 
in the art should readily appreciate that the signal flow diagram shown in FIG 1 C is an 
abstraction of the network 1 98 shown in FIG. IB, having only relevant entities shown 
theremForexampl^theterminal-l 172Aandterminal-2 172B are provided with the signal 
paths 1 73 A and 1 73B, respectively, for interfacing with the user profile repository 1 68 
Also, signal paths 187A and 187B are provided between the service node converter 
•nterface 188 and the two terminals, respectively, foraccessing the SGP service node 190 
As can be readily seen, GK-1 174A is not provided with a signal path to the user profile 
repos t toryl68 in this exemplary embodiment. However, it should be understood by those 
skilled in the art that in some implementations, a gatekeeper and/or other IP entities for 
example, anMGC, may also be provided with respective signal paths to either the user 
profile repository 168, service node converter interface 188, or both. Furthermore a 

provisionmaybemadeforservicetriggeringoveraradiointerface(e.g.,aGeneralPacket 
Radio System (GPRS) interface). 

Theadvantageousfeatureofprovidingaccesstosemcenodes from several types 
oflPentitiesis enabled by providing a common framework for call control, service access 
^dj^ingw^^ 

wWchillustratestherelationshipbetweencall/connectioncontrol^ 
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with the teachings of the present invention. It should be realized that this functional model 
is independent of the particular standard used for IP telephony and, accordingly, provides 
a universal service invocation and realization architecture for implementing VAS in IP 
telephony networks. Essentially, the service invocation and realization architecture is 
5 comprised of the following: 

- One or several IP telephony call control modules (e.g. , module 202), which 
-- integrate the IN-derived Detection Points (DPs) and implement an API 

which allows services to influence ongoing calls. The call control modules 
may be implemented in terminals, H.323 gatekeepers, SIP proxies, in 
10 MGCs, or any node in the network that is capable of effectuating call 

control. 

- A Service Access module (e.g., Service Access server 204) responsible 
for the invocation of VAS, whose functionality is preferably distributed 
between a Service Access component/instance and one or more 

1 5 specialized service proxies (shown in FIG. IB and described hereinbelow) 

which actually invoke services on behalf of the Service Access component 
and mediate between the services and the call control, if necessary. 

- Services (more universally, Service Logic Environment 206) which may be 
implemented using several technologies, e.g., IN/AIN/WIN Service 

20 Control Points, non-IN-related application servers (e.g., Parlay application 

server), call control-resident services (e.g., Java executables), service 
scripts (e.g., SIP CPL, SIP CGI, etc.), or mobile agents. 

- A user profile (described in greater detail hereinbelow with respect to FIG. 
2D) which is used by the various components to invoke the right services 

25 at the right time. This user profile may partly be co-resident with the call 

control module, or reside at a remote location that is retrievable. In 
addition, the profile may preferably be modifiable by various applications, 
including services implemented as mobile agents. 
It should be realized that the universal seivice invocation and realization architecture 
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set forth above advantageously reconciles existing as well as those yet to come IP VAS 
solunons in a coherent and powerful execution and realization environment 

Functionally, when the call/connection control module 202 .activated pursuant to 
a call being made by an IP entity such as, for examp.e, a caning party, a called party 
^ tekee P->°ranMGC,asu^ 

forprovdmgamechanismfordetecting when the control needs to be passed to the Serv 1Ce 

Accesssen,ermodu.e204.As S etfo rt habove,theserviceproxyactual,yinvolcesservices 
on behalf of the Service Access component therein and operates a mediating interface 

betweentheservicesandthecallcomrol. Preferably, the functionality ofthe Service Access 

--er2CMincludesdeterminin g serviceeventsandtheirorder based on the inputs - and 

poss I blyotherconditions,,g.,time-fromthecall/connectioncontrolmodule202 The 

Serv,ceAccessserver204alsodetermines t helocationofappro P riate S ervicelogic(WIN 

ofthe service proxies may include the following tasks: 

- encapsulate service triggers, etc.; 

- mediate between service client and service server by using appropriate cal, 
models, protocols, logics, et cetera; and 

- provide event buffering. 

The service logic environment 206 induces appropna,e service logic and opera.es as a 
serverfor,heservieesprov i dedbythene t wor k ., tistypicallyimplemenWKa ^. ceor 
apphea«,on node in the network and is eonpled to the Service Access server 204 via any 
sunable interface such as for example, HTTP, Java RMI, Corba, ASCII/IP etc 

Furthermore, as wilibeexplainedhereinbeW.someoftbeservicesmaybelocalaawell 

Frontaserviceexecution perspective, thethreemodulesinter-operateasfollows 
The caU/connection control module 202 preferably corresponds to the functionality of 

WIN/INCallCon,ro 1 Fu„c«io„(CCF, I,impleme„.s<heCCSM208 .handlescal, -related 

Mser.me^ionsand^aling.andpetfonosbasiccalleontrolprocessing.hsconneaion 
^ep^odngofVAS^^^ 

<he.ypeofDPorDPsencoun.ered, crea t i„ga S ervice Access component as par, of, he 
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Service Access server and passing control information thereto when call processing is to be 
suspended, and handle VAS answers and/or requests. 

The service proxies of the Service Access sen/er handle interactions with the service 
logic, whether it is local or stored at a remote location. The service proxies may also 
5 evaluate service criteria, sequence service triggers (also referred to as Feature Interaction 

Management or FIM), generate actual triggers and handles requests from the service logic 
environment 206. 

The service logic environment 206 executes appropriate service logic or logic 
portions ("logics") It may be provided either locally or remotely with respect to the 

1 0 call/connection control module 202. In accordance with WIN architecture, the service logic 

environment 206 preferably comprises an SCP node that is accessed remotely. It arbitrates 
and resolves contentions among multiple service logics for execution, if necessary. 

From a VAS perspective, the responsibilities of each functional module are as 
follows: The call/connection control module 202 is preferably provided with the awareness 

15 as to when services may possibly be executed . Preferably, this knowledge comes with the 

initial retrieval of the end-user profile from the user profile repository 1 68 (depicted in FIG. 
IB). However, in a presently preferred exemplary embodiment ofthe present invention, 
the call/connection control module 202 may not possess any knowledge with respect to 
whether a service is in fact to be executed, and if so, whether one or more services are to 

20 be sequenced and what the services are. 

The service proxies are preferably provided as modules which evaluate whether one 
or more services are to be executed or not. In a presently preferred exemplary 
embodiment, these proxies do not know what the services are, although they are aware of 
the specific service invoking mechanisms. The service logic environment module 206 is the 

25 module that is actually aware of the services to be executed. Preferably, based on the 

decisions taken by the service logic or logics, it provides a unique answer to the proxies in 
the Service Access server 204. 

As stated elsewhere in the patent application, the present invention is directed to 
providing the capability in IP entities such as terminals (H.323 or SIP), etc. of accessing 
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service nodes that are preferably WIN/IN-compliant and taking an appropriate action 
based on the result or results obtained therefrom. In other words, the IP entities are 
preferably provided with switching functionality necessary for taking service-related actions 
themselves. As will be described in greater detail hereinbelow, the CCSMs of the IP 
entities are modified in accordance with the teachings of the present invention so as to 
facilitate the foregoing objects. 

Referring now to FIG. 2B, a functional block diagram of a VAS-enabled entity 
(e.g., an enhanced terminal) is shown therein for illustrating the various aspects ofthe call 
control and service access process described hereinabove. A user interface 402 is 
provided for interacting with the end-user. It accepts requests from the user (e.g., call 

initiation, call abandon, orcall release), obtains necessaryinformationtoproceed(e.g.,a 
phone number, authentication information, etc.), notifies the end-user about call-related 
events (e.g. , another call attempt while a communication session is ongoing), and preferably 

potentiallypromptstheuserforadditionalinformation(e.g, an authorization password) or 
call-related decisions (e.g., how to deal with other call attempts during an ongoing 
communication session). 

Acall signaling server 404 is provided for decoding, validatingand interpreting call 
signaling messages received from other network entities. Preferably, it may also issue 
messageconfirmations, if required. In anH.323/H.450-based VoIP network embodiment, 
the call signaling server 404 receives messages from other H.323 entities such as, for 
example, aterminal, gateway, or a gatekeeper. These messages are defined by the H.225 . 0 

specification, andmayincludeaSupplementaryService(SS)message(in accordance with 
H.450.X Recommendation series) encapsulated therein. Accordingly, in this exemplary 
embodiment, thecall signaling server 404 is provided with the capability to extract such 
encapsulated SS messages. 

From the implementation standpoint, the call signaling server 404 may preferably 
be implemented as a dynamic library or as a separate software module. Furthermore, it 

jnaybecombh^withacansi^^ 

signaling client 414 translates call control intentions into appropriate signaling messages sent 
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to other IP telephony entities. Similar to the call signaling server 404, the call signaling client 
414 is preferably operable with multiple IP protocols, e.g., SIP, H.323, et cetera. 

A call manager 406 is provided as a module that treats call setup requirements. In 
some exemplary embodiments, it also treats call release requests if they are not treated 
5 directly by the call control module 4 1 0. When an end-user initiates or ready to answer a 

call, and when the terminal or appliance is registered with a gatekeeper (in an exemplary 
H.323-based network embodiment), the call manager 406 requests access to the 
gatekeeper (for example, by using the Registration and Access Status (RAS) messages). 
If the access is granted, the call manager 406 creates an Originating or a Terminating call 
1 0 control 4 1 0, depending on whether the terminal is the originating or terminating party of the 

call. Thereafter, it passes the necessary information to the call control 4 1 0 (e. g. , a calling 
party number, a called party number, etc.). When the call manager 406 is requested to 
complete or abandon a call, it preferably deletes the corresponding call controls also. 
The call control 4 1 0 manages a call - from setup to termination - on behalf of one 
15 of the call parties (originating or terminating). A call party is characterized by the 

combination of the end-user and the terminal/appliance involved in the call. Accordingly, 
an Originating CC SM (0_CCSM) and a Terminating CCSM (T_CCSM) are provided for 
the call management. Where an H. 323-based network is used, the CCSMs are preferably 
both H.323- and WIN-compliant in accordance with the teachings of the present invention. 
20 In analogous fashion, where a SIP-based network is used, the CC SMs are SEP- and WIN- 
compliant. Preferably, as will be described in greater detail hereinbelow, the CCSMs 
(whether H.323 -based or SIP-based) implement aQ.931 user-side-based state machine, 
augmented by WIN Detection Points (DPs - points in a call processing sequence where the 
processing may be suspended (because of the particular type of DP encountered) and 
25 control is passed to a Service Access component created in the Service Access server 

204), Points in Calls (PICs - points in a call processing sequence where the call processing 
can be resumed ), and additional states as may be needed. 

Preferably, the call control 410 is started by the call manager 406. As to its 
termination, it may stop by itself or based on a decision by the call manager 406. When 
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started, ^epn^ task of thecal, control 410 is to obtain a list of the DPs to be arxned 

Th.shst.aybestoredloca^or.aybeprovided^auserprof.eretneve^ 

«n the CCSM of the call control 410 may result from the following. 

- call signaling received from an IP entity via the call signa.ing server 404; 

- mput from the end-user via the user interface 402; 

- result or request from the Service Access server; 

- result of call control processmg which preferably includes the following 

- treatment of received call signaling; simple tasks may be performed 
locally, more complex ones may be delegated to other modules 

-interactionswiththeend-userthroughtheuserinterface402,ifneeded 
and 

" generation of call signaling. 
As stated elsewhere, when the caf. control meets an anned DP, it may suspend 
process i n g ba S edon.he M , ure of t heDP^ lproceKing ; snotstopMtheca||comro| 
creates a suirable Setv,ce Aecess component and passes relevant informal Mso 
processing resumes (with a possiblejump t0 a specified P,C) when the Service Access 
server answers, and accordmg to the answer. ,„ a prese„„ y preferred exempt 
-b O d. me „ t ,whe„,heca l ,co„,ro,4 1 0,e™ma,esfor any reason, i, may be retired to 
nottfy thecal, manager 406 before doing so. Furthermore, .Interaction between the 

serv,ce S a n d t heca, l co„.o l mayb= P erformedei,herdirec. 1 y ( i.e.,,oca,se™ces)orv 1 aa 
remote service proxy (e.g , WIN, remote services, CPL services) 

Still cominuingtoreferfono 2B , he VASmnc^onaii^oftheenhancedtermina, 

Value-AddedSe^cethathasbeenactivatedatnetworKleveiandfortheend-usertathe 

caseofanH.450.X-complia„ t archi,ec,ure, 1 heVASft 1 nc.i„na,i,yimpleme„ ts H450X 
se^ce-specific controls and may suppo* one or more roles defined in the H 450 X 

exemplar embodiments, the functionality may a,so impact an on . going ^ either 
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interacting with the call manager 406 (e.g. , to create or delete a call), or possibly with the 
call control 410 itself. 

The Service Access server 204 (comprising the Service Access instance and 
service proxies) is provided as the intermediary between the call control 4 1 0 and the service 
logics. Preferably, it makes services and the manner they are accessed or implemented 
transparent to the call control 410. When a service needs to take place, the call control 
may suspend call processing depending on the DPs type and, if the processing is to be 
suspended, it creates a Service Access component as part of the Service Access server and 
passes control to it, together with relevant information about the ongoing call. The Service 
Access server 204 eventually passes the control back to the call control 4 1 0 with relevant 
service-related instructions. In a further exemplary embodiment, these instructions may 
require that the call manager 406 be accessed directly for some reason (e.g. , termination 
of the call). 

Depending upon the implementation of the IP telephony network and the service 
provisioning therein, the knowledge about the DPs may be gained in a variety of ways. For 
example, a user profile retriever 4 1 9 is provided that retrieves the current user/terminal 
profile from the user profile repository 1 68, shown in FIG. IB. This profile includes a list 
of active triggers for the user/terminal combination, and therefore specifies the list of DPs 
to be armed . The user profile retriever 4 1 9 may retrieve this profile at start-up, or when 
explicitly requested by a client application and may be stored locally (possibly after retrieval 
of part or all of the profile information). In addition, the user profile may be directly 
accessed by the components which need them, i.e., call control, Service Access server 
(including the Service Access component, and possibly service proxies in some 
embodiments). 

When the call control 410 passes control to the Service Access server 204 
depending upon the type of an armed DP that is encountered, the Service Access 
component 4 1 6 created in connection therewith preferably evaluates if a service or services 
is/are to be executed, and if so, request for their execution, creates appropriate service 
proxies 417 accordingly. Thereafter, the Service Access server 204 answers the call 
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controltoresu m ethecallprocessse q uenceasithasbeendoing(,e.,thereisnos 

no ^hasani mm ed ia teirnpactonthecall).Accordingly,asstate^ 

call controMlOmaynotsystematicallystopcallprocessing -instead, the nature of the DPs 

encountereddete^nesthiscondition. If the on-going call is not to be stopped thecall 

control createsasuitableServ.ee Access component and passes call mformation to it, but 

does not stop or wait for the answer therefrom. 

Inthecontext 0 fserviceexecut 10 n,theServiceAccessco m ponent416evaluate S 
serv.cerequestsandcertaincriteriaassociatedtherewithinordertodecideifoneormore 
tnggersaretobegenerated. Preferably, the Service Access 4 1 6 evaluates these criteria 
m a pre-defined or nre-configured order so as to be able to generate the triggers and 

servcerequestsasdefinedrntheuserprofileCwhichmaybepotentiallyconflictin^inthe 

nghtorder.Whenatriggerhasbeengeneratedandansweredbyaserviceorapplication 
node, the Service Access server preferably proceeds as follows: 

-Iftheservicenodeaslcstoresumecallprocessingandthereisatleastonemore 
criterion left, the Service Access server evaluates that criterion. 

- If the service node's answer indicates resuming of the call control sequence at 
another PIC, the Service Access server commands the call control 4 1 0 to do so. 

- If there are no additional criteria to be evaluated, the Service Access server 
answers the call control 410 and stops processing. 

Preferably,theServiceAcces S serverstopsitsprocessingbyan S wering thecall controlto 

resumethecallprocesssequenceasithasbeendoin g (i.e.,thereisnoserviceornoservice 
has an immediate impact on the call). 

Ascanbeappreciatedbythoseskilled in the art, there may be multiple call controls 

410prov 1 dedatthesa me t 1 me(forexample,wheretheend-userconducts several callsin 
ParalleUrtheterminalimplementsaproxy call control), wherein each call control process 
may require or encounter its own DP/DP, Accordingly, a separate Service Access 

componentmaybecreatedeachtimeanewarmedDPisencounteredand, therefore, there 
_can be severa l jer^Access.components-for-a-single calb 



Referring now to FIG. 2C, shown therein is a flow chart of an exemplary 
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embodiment of a service provisioning method which captures the essence of the interactions 
of the several modules of the VAS-enabled entity described above, which is capable of 
accessing service/application nodes, including WIN/IN-compliant nodes. As described in 
the foregoing sections, the CCSMs of the VAS-enabled entity are preferably provided with 
one or more DPs, that are preferably WIN/IN-specific. However, because some of the 
WIN/IN DPs are primarily cellular-network-oriented, and therefore not relevant to the 
CCSM of an IP entity, such DPs are not included in the call/connection control module of 
the entity. Also, some DPs are not applicable to terminals (IP or otherwise) and, therefore, 
are not included 

Accordingly, during a call processing step 210, when an armed DP is detected 
(decision block 212), a subsequent decision is made to verify if the DP is WIN/IN- 
compliant (decision block 2 1 4) requiring the creation of a suitable Service Access instance. 
Preferably, the information as to which DPs to be armed for a given end-user and terminal 
combination is accessed directly by the appropriate component i.e., call control, Service 
Access server (possibly including the service proxies). If no armed DP is detected, the call 
processing flow proceeds to subsequent steps which are typically implementation-specific 
(step 220). If the WIN/IN-specific DP is encountered, on the other hand, a new Service 
Access component is created as part of the Service Access server for accessing the 
appropriate service logic or logics in a service/application node (step 216). After the 
execution of the service logics, suitable answer or answers are provided to the Service 
Access server which determines the next step in the call processing sequence. These steps 
are comprehended in steps 218 and 220 of the flow chart. 

Those of ordinary skill in the art should understand upon reference hereto that the 
determination of whether a DP is WIN/IN-compliant, shown in decision block 2 1 4, may 
preferably be avoided by a service provisioning method in some exemplary embodiments. 
Accordingly, it should be understood that it is not always necessary to check whether the 
DP is WIN/IN-compliant or not . Regardless, if the DP requires the creation of a Service 
Access instance and possible suspension of the call processing, it will be done accordingly. 
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FIG. 2D depicts a generalized user profile model preferably used in conjunction 
with theuniversal service invocation and realization architecture depicted hereinabove with 
respect to FIG. 2A. It should be apparent to those skilled in the art that the 
implementations shown in FIGS. IB and 1 C illustrate particular embodiments (H.323- 

based)thatareencompassed within the teachings ofthe generalized user profile model set 
forth herein. 

As briefly stated in reference to FIGS 2A and 2B, a user profile 26 1 (preferably 

utilizedastheuserprofilerepositoryl68inFIGS.lBandlCorrepository318inFIG3 
described below) is preferably provided to be interfaced by the various components ofthe 

serviceinvocationandreaJizationarchitectureinordertoinvoketheappropriateservices 
at the appropriate time. The user profile 26 1 preferably includes the DPs to be armed for 
both Terminating and Originating CCSMs. For each DP, a sequence is specified: 

condition of invocation - condition based on call data and/or any other 

relevant data(e.g, date, time etc.). May also be TRUE if unconditional invocation. 

<service type> =* may be WIN, CPL Script, Local Service, Mobile Agent, etc. 

invocation information - any relevant information for the invocation besides 

calldata.Forexample,inthecaseofWIN,thetriggertype,andtheIPaddressfor 
the SCP. 

Auserprofileretriever255(whichmaypreferablybeutiUzedastheprofileretriever 
419depictedinFIG.2B)isprovidedforretrievingauserprofilethati S relatedtoservices. 
Preferably, an appropriate interface, e.g., LDAP, HTTP, etc., is used for this purpose. One 

ormorelocaladniinistrativetools257maybeusedforcreatinguser P rofile^^ 
respecttothelocalservicesofasubscriber. Services implemented as Mobile Agents 259 
create appropriate related profile information upon arrival. 

Taking FIGS. 2A and 2D together now, the components ofthe service invocation 
andrealizationarchitecturemay&rtherbedescribedmtermsofthd 
Each time an armed DP is encountered, a Service Access (SA) instance (e.g., Service 
Accej^component4^ 



type. While the SA module has no knowledge ofthe actual services to be invoked, it 
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possesses knowledge as to the sen/ice invocations and, once created, the S A instance may 
proceed to one or several service invocations or none at all. The SA determines which 
invocations are to be performed, their priority, and how such invocations need to be 
effectuated. Preferably, the user profile provides such knowledge, whereas actual 
invocations are delegated to specialized components. 

Specialized service proxies (e.g., proxies 417 in FIG. 2B) are provided for 
implementing the specific aspects of different service environments. A Local Service Proxy 
may be provided for starting a local service and pass call parameters to it. Similarly, a 
Mobile Agent Proxy mediates between the call control and the mobile agent or mobile 
agency. ALocal Script Proxy is provided for interpreting a service script (e.g., SIP CPL) 
and reporting its decision or decisions back to the call control. Also, an AS Proxy or WIN 
Proxy is provided for mediating between the call control and the external services. 

As can be seen from the foregoing, services embodying a particular service logic 
environment may be local, remote, or mobile. Accordingly, services may access local or 
remote data. Further, a service may exist only for the time to answer the invocation 
associated therewith, or exist for the entire call or a part thereof In addition, a service may 
have an immediate impact, deferred impact, or no impact on call control . In some instances, 
a service may not have any relevance with respect to call control at all . Preferably, services 
are provided with the capability to interact with the end-user and/or other applications- 
Referring now to FIG. 3, shown therein is a functional block diagram of a VAS 
architecture 300 provided in accordance with the teachings of the present invention. The 
VAS architecture 300 includes IP telephony entities, e.g., IP TEL entity 302 A and IP TEL 
entity 302B, VAS-enabled entities, e.g., IP TEL VAS-enabled entity 304, and VAS- 
specific entities. 

The VAS-specific entities preferably encapsulate , or responsible for, the relatively 
volatile part of telephony services which includes the service logics and end-user profiles. 
The service logics and the way they interact together are determined by the service logic 
environment 206. Services may be added or removed on the fly, by the IP telephony 
service provider (TSP), a third-party service provider, or the end-user. They may be 
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stored locally with respect to an IP TEL entity, remotely in a dedicated node (e.g., the 
service logic environment 206), or both. Appropriate logic and data 3 16 are included 
within an IP TEL VASclientS 14oftheIP TEL VAS-enabled entity 304forlocal service 
implementation. 

The end-user-and-terminal combination profile, which includes the set of services 

activatedfortheend-user/terminal,mayalsobestoredlocallyorremotelyinadedicated 
node(e.g.,profilerepo S1 tory318). In some implementations, both arrangements mayco- 
exist. When disposed in a separate node, the profiles are retrieved by using a retrieval 
interface 326 implemented in, for example, HTTP The access to the service logic 
environment 206 is implemented using a code mobility interface 328A and a service logic 
accessinterface328B. The code mobility mterface 3 28 A, typically used for retrieving some 
service logic code or VAS client code from the service logic environment 206, may be 
effectuated using a Java RMI protocol or a Mobility Agent protocol. The service logic 
access interface 328B may be based on the following: 

- IN AP/IP if the service logic environment 206 comprises a legacy IN or WIN 
SCP; 

- Corba or Java RMI if a programmatic interface is needed; or 

- an ASCII/IP interface (e.g., similar to SIP). 

The IP TEL entities are involved in the stable part of telephony services which 
typically consistsofthe set-up, control, and release ottP telephony calls. Forsupporting 
theprocessing and signaling related to this activity, an IP Basic Services (BS) peer 308 is 
provided withinthelPTELentitieswhic^inexemplary embodiments, include IP terminals, 
H.323 gatekeepers, gateways, SIP proxy and/or redirect servers, etcetera. Optionally, an 
IP TEL entity may also take part in the execution of a VAS, that is, it may be able to 

generateorprocesssomerequestsornotifications related to the service execution. An IP 
TEL VAS peer 3 06 is provided for effectuating such functionality. As an example, the IP 
TEL VAS peer 3 06 may be able to re-route a call setup request or may be notified that a 
call diversion ha s occur red. 

An IP TEL entity maybe VAS-enabled, e.g., entity304, when it is also capable of 
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determining which services should take place and when, and of taking the necessary 
measures to execute them using the IP TEL V AS client 3 1 4 that is connected to the volatile 
VAS-specific entities via the interfaces described above. The VAS-enabled entity 304 also 
includes its own VAS peer 3 1 0 and BS peer 3 1 2 for interfacing with other IP TEL entities. 

FIG. 4 depicts a WIN-compliant OCCSM for use with an H.323 or SIP terminal 
in accordance with the teachings of the present invention. FIG. 5 A depicts a WIN- 
compliant TCCSM for use with an H.323 terminal. And, FIG. 5B depicts a WIN- 
compliant T_CCSM for use with a SIP terminal. As stated hereinabove, the CCSMs of 
the present invention are preferably based on the Q. 93 1 user- side protocol originating and 
terminating state machines. These state machines are then rendered WIN-compliant by 
modifying according to the WIN originating and terminating Basic Call State Models 
(BCSMs), which add DPs and PICs at specific locations with the CCSM. Some WIN 
DPs and PICs are not retained in the terminal CCSMs because they are network-specific 
or not supported in the H.323 standard. 

The 0_CCSM for an IP terminal (H.323 or SIP terminal) is depicted in FIG. 4. 
Each of the states and associated DPs and PICs are described below. 

1 Null (State 502) 
Entry Event: 

Call is abandoned or cleared by the end-user (User Interface) (DP: 
0_Abandon or 0_Disconnect) 

Call is abandoned or cleared by network or called party (Release 

Complete) (DP: O Abandon or O Disconnect) 

Called party does not answer the call (Release Complete or Timeout) (DP: 

ONoAnswer) 

Called party is busy (Release Complete) (DP: OCalledPartyBusy) 

Exception handling 

PIC: 0__Null and OJException 

Functions: 

If the call has been abandoned or cleared by the end-user, issue a 
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disconnect (Call Release), notify end-user, notify call manager and 
terminate 

If the call had been abandoned or cleared by the called party, notify end- 
user, notify call manager and terminate 

If the called party is busy or does not answer, notify end-user, notify call 
manager and terminate 

If exception handling, process exception, notify end-user, notify call 
manager and terminate 
Exit Event: 

Called party number/address is provided (DP: Collected ^Information) 
Call is abandoned by end-user (DP: O Aandon) 
Call Requested-1 (State 514) 
Entry Event: 

Called party number/address is available (DP: Collected .Information) 

PIC: Analyzed lnformation 

Functions: 

None 

Exit Event: 

Call is abandoned by end-user (DP: O.Abandon) 

Automatic transition (DP: Analyzedjnformation) 

Call Requested-2 (State 516) 

Entry Event: 

No event required 

PIC: Send_Call 

Functions: 

Issue a call setup request (SETUP) 
Exit Event: 

Call is ab a ndoned b y end-us er „(DP:_Q_Abandon)_ 



Call setup request has been successfully issued 
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4 Call Initiated (State 504) 
Entry Event: 

Call setup request has been successfully issued 

PIC: No PIC 

Functions: 

Sets timer and waits for event 
Exit Event: 

Answer indicating that the called party is processing the call request (Call 
Proceeding) 

Answer indicating that the called party user is being alerted (Alerting) (DP: 
OTerm_Seized) 

Answer indicating that the called party user has answered the call 
(Connect) (DP: 0_ Answer) 

Answer indicating that the called party is busy (Call Release) (DP: 
0_Called_Party_JBusy) 

Answer indicating that the called party refuses the call (Call Release) (DP: 
OAbandon) 

Answer indicating that the called party requires more setup information 

(Setup Acknowledge) 

Timeout (DP: O No An s wer) 

Call is abandoned by end-user (DP: 0_Abandon) 

5 Overlap Sending (State 506) 
Entry Event: 

Answer indicating that the called party requires more setup information 
(Setup Acknowledge) 
PIC: No PIC 
Functions: 

Acquire necessary information (preferably via interaction with end-user) 
and send it (Information) 
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Exit Event: 

Answer indicating that the called party is processing the call request (Call 
Proceeding) 

Answer indicating that the called party user is being alerted (Alerting) (DP: 
0_Term_Seized) 

Answer indicating that the called party user has answered the call 
(Connect) (DP: 0_Answer) 

Answer indicating that the called party is busy (Call Release) (DP. 
0_Called_Party_Busy) 

Answer indicating that the called party refuses the call (Call Release) (DP: 
OAbandon) 

Answer indicating that the called party requires more setup information 
(Setup Acknowledge) 

Call is abandoned by end-user (DP: 0_Abandon) 
End-user requests a feature (DP: O Mid Call) 
Timeout (DP: 0_No_Answer) 
Outgoing Call Proceeding (State 508) 
Entry Event: 

Answer indicating that the called party is processing the call request (Call 

Proceeding) 

Functions: 

Notify the end-user that the setup request has been answered 
Set timer and wait for event 
Exit Event: 

Answer indicating that the called party user is being alerted (Alerting) (DP: 
OTermSeized) 

Answer indicating that the called party user has answered the call 

( Connect) (DP: O Answer) 

Answer indicating that the called party is busy (Call Release) (DP: 
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0_Called_PartyJ8usy) 

Answer indicating that the called party refuses the call (Call Release) (DP : 
0_Abandon) 

Timeout (DP: 0_No_Answer) 
5 Call is abandoned by end-user (DP: 0_Abandon) 

End-user requests a feature (OMid_CalI) 

7 Call Delivered (State 510) 
Entry Event: 

Answer indicating that the called party user is being alerted (Alerting) (DP: 
1 0 0_Term_Seized) 

PIC: 0_Alerting 
Functions: 

Notify the end-user that the called party is being alerted 
Wait for event 
1 5 Exit Event: 

Answer indicating that the called party user has answered the call 
(Connect) (DP: 0_Answer) 

Answer indicating that the called party is busy (Call Release) (DP: 
0_Called_Party_Busy) 

20 Answer indicating that the called party refuses the call (Call Release) (DP : 

OAbandon) 

Call is abandoned by end-user (DP: 0_Abandon) 
End-user requests a feature (O JVIid_Call) 

8 Call Active (State 512) 
25 Entry Event: 

Answer indicating that the called party user has answered the call 
(Connect) (DP: 0_Answer) 
PIC: 0_Active 
Functions: 
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Notify session manager (H.245) that the call is active 
Wait for event 
Exit Event: 

End-user requests a feature (DP: OMidCall) 
5 End-user clears the call (DP: 0_Disconnect) 

Receives disconnect message from network or called party (Call Release) 
(DP: O Disconnect) 
FIG. 5A depicts an H.323 terminal's T_CCSM in particular detail. Eachofthe 
states shown therein and associated DPs and PICs are described below 
10 1 Null (State 602) 

Entry Event: 

Call is abandoned or cleared by calling party or network (Call Release) 
(DP: TAbandon or TDisconnect) 

Call is abandoned or cleared by end-user (User Interface) (DP: 
1 5 T Abandon or T Disconnect) 

End-user does not answer the call (User Interaction Timeout) (DP: 
T_No_Answer) 

End-user is busy (communication appliance is busy or end-user says so) 
(DP: T_Busy) 
20 Exception handling 

PIC: T_Null and T_Exception 
Functions: 

If call is abandoned or cleared by calling party or network, notify end-user, 
notify call manager, and terminate 

25 If the cal1 has been abandoned or cleared by the end-user, issue a 

disconnect (Call Release), notify end-user, notify call manager and 
terminate 

/- 

!f end-user does not answerthe_call,.issue disconnection request-(Gall- - 

Release), notify call manager and terminate 
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If exception handling, process exception, notify end-user, notify call 
manager and terminate 
Exit Event: 

An indication of incoming call has been received (Setup) (DP: 
Facility_Selected_and_Available) 
Call Present (State 604) 
Entry Event: 

An indication of incoming call has been received (Setup) 

PIC: Present_Call 

Functions: 

In case no more information is required, issue a corresponding indication 
(Setup Acknowledge) 

Otherwise, unless the end-user has decided otherwise, issue an indication 
that the setup request has been received (Call Proceeding) 
If the end-user has explicitly stated to do so, alert the end-user and issue 
and altering indication (Alerting) 

If the end-user has explicitly stated to do so, directly accept the call by 
issuing a corresponding indication (Connect) 

If the end-user has explicitly stated to do so, directly reject the setup by 
issuing a corresponding indication (Call Release) 
Exit Event: 

A call proceeding indication has been issued (DP: 
Facility_Selected_and_Available) 

An alerting indication has been issued (DP: Call_ Accepted) 

A connect indication has been issued (DP: T_Answer) 

A call release indication has been issued (DP: T_No_Answer) 

A call release indication has been received (DP: T_Abandon) 

Call Proceeding (State 606) 

Entry Event: 



BNSDOCID: <WO 0O42760A1_l_> 



PCT/SE99/02490 



-30- 

A call proceeding indication has been issued 

PIC: Present Call 

Functions: 

Present the call to the end-user and set a short timer 
Iftheend-user cannot be contacted, issue a busy indication (Call Release) 
Otherwise, if the end-user answers the call before the timeout, issue an 
indication that the call is accepted (Connect) 

Otherwise, issue an indication that the end-user is being alerted (Alerting) 
Exit Event: 

A call release indication has been issued (DP: T_Busy) 

An indication that the end-user is being alerted has been issued (DP: 

CallAccepted) 

An indication that the call is answered has been issued (DP: 
CallAnswered) 

A call release indication has been received (DP: T_Abandon) 
Overlap Receiving (State 608) 
Entry Event: 

A setup acknowledge indication has been issued 
An Information message has been received 
PIC: No PIC 
Functions: 

Wait for an Information message 
Analyze the information 

If still not enough, issue another Setup Acknowledge indication 
In enough information has been received, present the call to the end-user 
If the end-user cannot be contacted, issue a busy indication (Call Release) 
Otherwise, issue and indication that the end-user is being alerted (Alerting) 
Exit Event: 



An Information message has been received 
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A call release indication has been issued (DP: T Busy) 

An indication that the end-user is being alerted has been issued (DP: 

CallAccepted) 

An indication that the call is answered has been issued (DP: 
5 Call_Answered) 

A call release indication has been received (DP: T_Abandon) 

5 Call Received (State 61 0) 
Entry Event: 

An indication that the end-user is being alerted has been issued (DP: 
10 - Call_Accepted) 

PIC: T_Alerting 
Functions: 

Set a timer and wait for a response from the end-user 
If the end-user answers the call, issue a corresponding indication (Connect) 
1 5 If the end-user refuses the call, issue a corresponding location (Call 

Release) 

After timeout, issue an indication that the end-user does not answer (Call 

Release) 

Exit Event: 

20 A call release has been issued (DP: T_No_ Answer) 

A call release has been received (DP: T_Abandon) 
A connect indication has been issued (DP: T_Answer) 

6 Call Active (State 612) 
Entry Event: 

25 A connect indication has been issued 

PIC: T_Active 
Functions: 

Notify session manager (H.245) that the call is active 
Wait for event 
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Exit Event: 

End-user requests a feature (DP: T_Mid_Call) 
End-user clears the call (DP: TDisconnect) 

Receives the disconnect message from network or called party (Call 
Release) (DP: T Disconnect) 
FIG. 5B depicts a SIP terminal's T_CCSM in particular detail. It should be 
realized that the SIP terminal's TCCSM is substantially similar to that of the H.323 
terminal described in greater detail above. Accordingly, only the salient differences 
therebetween are set forth below. 

Essentially, a new state, state 613, is added in the T_CCSM of a SIP terminal. 
7. Confirmation Awaited (State 613) 
Entry Event: 

A connect indication has been issued 

PIC: None 

Functions: 

Notify session manager that a confirmation of the call setup is awaited 
Wait for event 
Exit Event: 

Confirmation ofthecall setup has beenreceived from the calling party (DP: 
T_Mid_Call) 

End-user clears the call (DP: T Disconnect) 

Receives the disconnect message from network or called party (Call 
Release) (DP: T_Disconnect) 
In addition, it should also be noted that the DPs and PICs associated with the Call 
Active state, which is now entered from the Confirmation Awaited state, are is 
appropriately modified. Also, no specific entry event is required for this state. 

FIGS. 6Aand6B depict message flow diagrams for two exemplary embodiments 
of a call diversion service, respectively,^,^ 



invention. While it is well-known, the H.323/H.450 framework supports several "flavors" 
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of call diversion (SS-DIV flavors, for example, Call Forward Unconditional (SS-CFU), 
Call Forward Busy (SS-CFB), and Call Forward No Reply (SS-CFNR)), there is no 
provision for a time-dependent Call Forward service. FIGS. 6 A and 6B illustrate how the 
existing H 450 services may be enhanced or extended by using the teachings of the present 
invention. 

Referring in particular to FIG. 6 A, a message flow diagram of an exemplary 
embodiment of a time-dependent Call Forward service is shown therein. When terminal- 1 
1 72 A (TA) issues a Call Setup request 1 1 02, terminal-2 1 72B (TB) responds by a Call 
Proceeding message 1 104, indicating that TB will subsequently answer the request. 
Thereafter, TB's T CCSM encounters an armed DP (Facility_Selected_and_Available) 
and generates a corresponding trigger 1 1 06 to the SCP 1 90. Pursuant to the DP, the call 
control is passed to the SCP 1 90 which provides an appropriate Result 1 108. The SCP 
1 90 is aware that a Call Forward service dependent on date and time has been set up for 
the subscriber/TB combination and that the call should be diverted to terminal-3 1 72C 
(TC). The Result 1 1 08 from the SCP 190 contains the appropriate instruction for the call 
diversion. 

Responsive to the Result 1 1 08 from the SCP 1 90, TB issues towards TA 1 72 A an 
H.225.0 Facility message 1110, including an encapsulated H.450.3 Call Re-Routing Invoke 
request. T A 1 72 A accepts the request by issuing an acknowledgment message (Facility) 
1112 and releases the call by sending a Release Complete message 1 1 14 to TB 172B. 

Thereafter, TA 172 A issues a Call Setup message 1 1 16 to TC 172C, with an 
H.450.3 field indicating that the call has been re-routed from TB 172B. TC 1 72C directly 
informs TAthat the subscriber is being alerted by issuing an Alerting message 1118. Once 
the subscriber answers the call, a Connect message 1 120 is sent from TC to TA. 

The message flow diagram depicted in FIG. 6B illustrates a variation on the time- 
dependent Call Forward service described above. It can be readily seen that the messages 
are essentially similar and, accordingly, only the salient features are set forth below. 

Once the T_CCSM of TB 172B encounters the armed DP 
(Facility_Selected_and_AvaiIable), the call control is passed to the SCP 190 which is 
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aware that the a Call Forward service dependent on date and time has been activated for 
the subscriber/terminal-2. If, for some reason, the call shouldnotbe diverted atthe selected 
date/time, TB is instructed to resume normal call processing, by sending an appropriate 
Result 1208 thereto. Thereafter, TB instructs TA that the subscriber is being alerted 
(Alerting 1210) and that the call is established (via a Connect message 1212). 

FIG. 7 depicts a message flow diagram for an exemplary embodiment of a hunt 

groupserviceprovidedinaccordancewiththeteachingsofthepresentinvention. Whenthe 
end-user, TA 1 72A, requests for a Call Setup, providing as number the identification of a 
Virtual Private Network (VPN) group, the 0_CCSM of TA 172A stops upon 
encountering armed Collected Jnformation and Analyzedjnformation DPs and a trigger 
is provided to the SCP 1 90. Responsive thereto, the SCP 1 90 determines that a hunt 
group service is to be executed. That is, a call setup must be attempted with a list of the 

tenmnatingparties,inapre-definedorder,untiloneofthemeventuallyanswersthecall. In 
one embodiment, the SCP 1 90 may simply provide the list of numbers to TA 1 72 A and 
stop, provided TA 1 72 A is VAS-enabled to handle such a«md execute the associated 
logic. In an alternative embodiment, the SCP 1 90 may instruct the terminal step-by-step 
as to what needs to be done. The message flow diagram in FIG. 7 contemplates this 
alternative scheme. 

When the control is passed to the SCP via trigger 1 302 on account of the armed 
DP,theSCP 190 instructs TA 172A (via Result 1 304) to set up a call with TB 172B,and 
dynamically arms the following DPs. 0_No_Answer, 0_Called_PartyJBusy, and 
0_Answer. Thereafter, TA 1 72B sends a call setup request 1 306 to TB 172B. A Call 
Proceeding message 1308 is issued to TA 172A, indicating that TB will subsequently 
answer the request. TB alerts the end-user (Alerting 1310), but nobody answers the call . 

Asaconsequence,TBissuesaCallReleaseCompletemessagel312indicating that there 
isnoanswerto the call setup attempt by TA 172 A. The 0_CCSMofTA encounters the 
0_No_Answer DP and issues a corresponding event 1 3 1 4 to the SCP 1 90. The SCP 1 90 
thenproceeds to the next number inthehunt groupJist,-reTequests<via^result-l 3 1 6) the- - 



terminal (TA)toattemptacall setup with TCterminal, and dynamically arms the sameDPs 
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as set forth above with respect to the TB call setup. 

TA 1 72 A sends a Call Setup 1 3 1 8 to TC 1 72C which returns a Release Complete 
message 1320, indicating that there is no answer. Once again, the OCCSM of TA 
encounters the 0_No_Answer DP and issues a corresponding event 1 3 22 to the SCP 1 90 . 
5 The SCP takes the next number in the hunt group list and proceeds in the same manner as 

described hereinbefore. In this illustration, terminal TD 1 72D of the list answers the call and 
provides a Connect message 1330toTA. Thereafter, the 0_CCSM of T A encounters the 
O Answer DP and issues a corresponding notification 1 3 32 to the SCP 1 90 to terminate 
its service logic. 

1 0 - Referring now to FIGS . 8A-8F, depicted therein are several examples of service 

invocation and realization in accordance with the teachings of the present invention. An 
Originating CCSM, such as one discussed in detail hereinabove with respect to FIG. 4, with 
appropriate DPs is exemplified in these exemplary embodiments. Self-explanatory 
scenarios involving local access, mobile agent access, external SCP access, etc. are 

15 illustrated. 

Based upon the foregoing, it should be readily appreciated by those skilled in the 
art that the present invention provides an advantageous solution for accessing service nodes 
from end terminals disposed in an IP network by combining the service architectures from 
the IP and WIN/IN realms into a hybrid approach. Because in the present invention the 

20 terminals are allowed to access the service logics in a remote location, the limitation of 
reduced number of services available within a terminal has been overcome. Further, 
because the service logics can resolve conflicts and contentions among services and their 
execution, service interaction issues that are prevalent in the IP-based service architectures 
have been resolved. On the other hand, the scalability issues common to the network - 

25 centric WIN/IN approach have been eliminated on account of the integration of the IP 
service architecture. 

In addition, deficiencies in the current technologies with respect to service mobility 
are also overcome. Because the IP terminal is in a client-server relationship with the service 
node server, the mobility of the terminal is no longer a constraint on accessing the service 
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node server, which can be via INAP or IS-4 1 over SS7, or in some instances, via Java, 
Corba, etc. Moreover, service mobility is assured because if any intelligent appliance 
capable of accessing the Internet/WWW and download a piece of code, which essentially 
is a client's behavioral image expected by the service node server, the appliance can be 
used for accessing the services. Accordingly, a plethora of communication 
appliances/devices may be used in accordance herewith: Information appliances, 
personal/laptop/palmtop computers, Personal Digital Assistants, smart phones, 
TDMA/CDMA/GSM mobile phones, et cetera. 

Moreover, by utilizing the teachings of the present invention, the WIN/IN service 
logic base that is already installed and market-tested may continue to be re-used even as 
VoIP network architectures come into existence. Those of ordinary skill in the art should 
realize that there exist tremendous incentives, economic as well as infrastructure-based, for 
network operators to re-use the expensive legacy SCP nodes as they migrate towards 
integrating the cellular infrastructures with IP-based PSNs. Also, because the logic 
switching is provided within the terminal, services can be dynamically altered or allocated. 
For example, in thecurrent network-centric Call Forward-Unconditional (CFU) service, 
all calls are forwarded to a C-number whether or not the subscriber wishes to manually 
override the call forwarding. With the terminal logic provided in accordance with the 

teachingsofthepresentinvention,thetenninaIcaninterrogatethesubscriberfortheactual 
caUforwarding. Additionally, since some services maybe maderesident within theterminal 
itself, individualized service provisioning is possible. 

The advantages of providing IP-based VAS in accordance with the universal 
service invocation and realization architecture provided in the present invention may thus 
conveniently be summarized as below: 

permits flexible addition and/or removal of services; 

integrates various service implementations, ranging from "one size fits all" 

to extremely customized services; 

~ P^ils^he^euse_ofexisting-INAVIN-serviee-nodes, 

SCPs and Application Servers may deal with complex service interaction 
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issues and support universal access; 

applicable to various networks (e.g., SIP, H.323) and their V AS solutions 
(e.g., SIP CPL/CGI, H.450, IN-like, etc.). 
In particular, further advantages are evident when implemented in IP terminals: 
5 - makes use of terminal capabilities and relieves network nodes from V AS- 

related tasks; 

- implementation is simple and "lightweight"; 

- no constraint on network nodes to support standard call models and access 
to services (e.g., INAP, CAP, ANSI-41, etc.); 

10 - supports universal access to VAS; 

- favors interaction with end-user and other local applications (e.g., Web 
browser, etc.). 

Although the VAS architecture of the present invention has been exemplified with 
particular reference to a H.323-based IP network, it should be understood that other IP 

1 5 network implementations such as, for example, SIP-based networks, may also be used for 

practicing the teachings contained herein. In the case of a SIP-based network, DP- 
dependent service triggering may be performed from SIP terminals, SIP proxies or 
gateways, SIP redirects (collectively, SIP entities), wherein the SIP entities are provided 
with the CCSMs appropriately modified in accordance herewith. The call control 

20 functionality described hereinabove with respect to H.323 implementations is also applicable 
for a SIP-based implementation and, accordingly, a "dual mode" IP terminal that is SIP- 
as well asH.323-compliant, in addition to WIN/IN, maybe provided advantageously within 
an IP network. 

Further, it is believed that the operation and construction of the present invention 
25 will be apparent from the foregoing Detailed Description. While the method and system 
shown and described have been characterized as being preferred, it should be readily 
understood that various changes and modifications could be made therein without departing 
from the scope of the present invention as set forth in the following claims. For example, 
although the teachings of the present invention have been exemplified with a particular SS 
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withinthecontextoftheH.450.XRecommendations,itshouIdbeunderstoodthatother 
SSs undertheexistingorfutureH.450.XRecommendations may also be provisioned in 
accordance with the teachings of the present invention. That is, in addition to the Call 
Forward and hunt group services exemplified herein, the teachings hereof may be also 
applied in the context of numerous other services, for example, toll free and credit card 
calling, selective call restriction, click to fax, double phone / free phone, split charging, and 
multimedia applications such as tele-medicine, tele-education, video-on-demand, et cetera. 

Furthermore, while pluralities ofH.323-based terminals have been described in the 
exemplary embodiments of the present invention, any combination of non-H.323 entities 
such as mobile stations operable with a variety of air interface standards may be provided 
for the purposes of the present invention. The IP-based terminals may take several forms 
themselves. Personal Digital Assistants, Internet phones, laptop computers, personal 
computers, palmtop computers, pagers, and Information Appliances. In addition, the 
innovativeteachings contained herein may also be practiced in a VoIP network coupled to 
a PSTN, wherein the fixed entities can trigger service requests to a service node. 
Accordingly, it should be realized that these and othernumerous variations, substitutions, 
additions, re-arrangements and modifications are contemplated to be within the ambit of the 
present invention whose scope is solely limited by the claims set forth below. 
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WHAT IS CLAIMED IS: 

1 . A method of accessing a service node from an end terminal disposed in an 
integrated telecommunications network having a Voice-over-Internet Protocol (VoIP) 
network portion and a cellular network portion, the method comprising the steps of: 
5 providing an interface module disposed between the service node and the 

VoIP network portion; 

.. incorporating at least one detection point in a call control process provided 

with the end terminal, wherein the detection point operates to pass control to a service 
access server when the call control process encounters the detection point; 
1 0 determining, by the service access server, if a service needs to be executed; 

if so, sending a service request from the service access server to the service 
node for service execution; 

receiving, in the service access server, a result from the service node 
responsive to the service request, and 
1 5 passing the result from the service access server to the call control process. 

2 The method of accessing a service node from an end terminal disposed in 
an integrated telecommunications network as set forth in claim 1 , wherein the service 
request is sent from the service access server to the service node over a HyperText Transfer 
20 Protocol (HTTP) interface. 

3 . The method of accessing a service node from an end terminal disposed in 
an integrated telecommunications network as set forth in claim 1, wherein the service 
request is sent from the service access server to the service node over a Java interface. 

25 

4 . The method of accessing a service node from an end terminal disposed in 
an integrated telecommunications network as set forth in claim 1 , wherein the service 
request is sent from the service access server to the service node over a Corba interface. 
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5 The method of accessing a service node from an end terminal disposed in 
an integrated telecommunications network as set forth in claim 1, wherein the service 
request is sent from the service access server to the service node over an IP interface. 

6. A service provisioning method for invoking a Wireless Intelligent Network 
(WIN) service by an end terminal disposed in an integrated telecommunications network 
having a packet- switched network (PSN) portion and a cellular network portion, the 
method comprising the steps of: 

effectuating a call control process in the end terminal; 
determining, in the end terminal, if an armed detection point is encountered 
by the call control process; 

if so, creating a service access instance and passing control thereto; 
creating a service proxy associated therewith, 

accessing by the service proxy a service node disposed in the cellular 
1 5 network portion; 

executing a service logic portion in the service node to obtain a result; and 
providing the result to the call control process in the end terminal. 

7. The service provisioning method as set forth in claim 6, wherein the armed 
20 detection point is provided by a service access server disposed in the end terminal. 

8. The service provisioning method as set forth in claim 7, wherein the armed 
detection point is acquired by the service access server from a user profile repository 
disposed in the integrated telecommunications network, the user profile repository including 
a list of active triggers for the end terminal and a subscriber associated with the end terminal. 

9. The service provisioning method as set forth in claim 6, wherein the service 
logic portion co mprises a call diversion service. 



25 
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1 0. The service provisioning method as set forth in claim 6, wherein the service 
logic portion comprises a hunt group service. 

1 1 . The service provisioning method as set forth in claim 6, wherein the service 
5 logic portion comprises a time-dependent call diversion service. 

1 2 . The service provisioning method as set forth in claim 6, wherein the service 
node is accessed using a HyperText Transfer Protocol (HTTP) interface. 

10 13. The service provisioning method as set forth in claim 6, wherein the service 

node is accessed using a Java interface. 

1 4 . The service provisioning method as set forth in claim 6, wherein the service 
node is accessed using a Corba interface. 

15 

1 5 The service provisioning method as set forth in claim 6, wherein the service 
node is accessed using an IP interface. 

16. An integrated telecommunications network comprising: 

a packet-switched network (PSN) portion including one or more end 

terminals; 

a circuit-switched network (CSN) portion coupled to the PSN portion via 

a gateway; 

a service node disposed in the CSN portion, the service node including 
service logic portions for executing one or more services and being coupled to the PSN 
portion via an interface; 

a user profile repository disposed in the PSN portion, the user profile 
repository including a list of triggers for a particular end-terminal-and-subscriber 
combination, 
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call control means in the end terminal for controlling a call process; 

a service access server in the end terminal that evaluates service requests 
and creates service proxies based thereon, 

wherein the call control means passes control to the service access server 
5 when an armed detection point based on the list of triggers is encountered in the call process 
such that a service proxy places a request to the service node for executing a service logic 
portion. 

1 7 The integrated telecommunications network as set forth in claim 1 6, wherein 
1 0 the interface comprises a HyperText Transfer Protocol (HTTP) interface. 

18. The integrated telecommunications network as set forth in claim 1 6, wherein 
the interface comprises a Java interface. 

15 19 The integrated telecommunications network as set forth in claim 1 6, wherein 

the interface comprises a Corba interface. 

20 The integrated telecommunications network as set forth in c^^^^^^ein 
the end terminal is selected from the group consisting of a Personal Digital Assistant, an 

20 Internet phone, a laptop computer, a personal computer, a palmtop computer, a pager and 
an Information Appliance. 

21 The integrated telecommunications network as set forth in claim 16, 
wherein the PSN portion comprises an H.323 network and the end terminal comprises an 

25 H.323 terminal. 

22. The integrated telecommunications network as set forth in claim 16, 
^ereinthej^ 



terminal. 
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23 . An integrated telecommunications network having a generalized service 
invocation and realization architecture, comprising: 

one or more call control modules including a plurality of service-related 
detection points that are Intelligent Network (IN)-compliant; 
5 a Service Logic Environment implemented to execute a service logic 

portion; 

a Service Access server coupled to the Service Logic Environment, the 
Service Access server including a Service Access component created when an armed 
detection point is encountered and one or several service proxies operating to invoke a 
1 0 service on behalf of the Service Access component, the service proxies mediating between 

the Service Logic Environment and the call control modules; and 

a user profile structure specifying the information as to when a service is to 
be invoked for a particular mobile subscriber. 

15 24. The integrated telecommunications network as set forth in claim 23, 

wherein the service logic portion corresponds to a local service. 

25. The integrated telecommunications network as set forth in claim 23, 
wherein the service logic portion corresponds to a mobile agent-based service. 

20 

26. The integrated telecommunications network as set forth in claim 23, 
wherein the service logic portion corresponds to a remote service residing in a Service 
Control Point (SCP) node. 

25 27. The integrated telecommunications network as set forth in claim 23, 

wherein the call control module resides in an H.323 terminal. 

28. The integrated telecommunications network as set forth in claim 23, 
wherein the call control module resides in an H.323 gatekeeper. 
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29. The integrated telecommunications network as set forth in claim 23, 
wherein the call control module resides in a SIP entity. 

30. The integrated telecommunications network as set forth in claim 23, 
5 wherein the call control module resides in a Media Gateway Controller. 
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